1. Field
This invention relates to processing of messages in a web services framework, and more particularly to a method and a system for processing an application transaction in a web services system.
2. Background
A web service is a software application to support interoperable machine to machine interaction over a network. The term “web service” is to be understood as a technology that allows software applications to communicate with each other and can be used to engage in business relationships (e.g., buying and selling) in a partially or wholly automated fashion over a public network such as the Internet. Standards bodies and interoperability organizations that have contributed to the web services effort include the World Wide Web Consortium (W3C), the Organization for the Advancement of Structured Information Standards (OASIS), the Internet Engineering Task Force (IETF) and the web services Interoperability Organization (WS-I).
The web services architecture as an instance of a typical Service Oriented Architecture (SOA) includes two types of web service applications: a web service provider and a web service consumer. The web service provider is the provider of one or more web services that can be accessed over the network and the web service consumer is generally understood to be an entity that seeks and (in cases where a suitable web service is found) uses a particular web service through a network. The web service provider could be also a web service consumer. The communication between the web service provider and the web service consumer in the web services architecture is implemented through an exchange of Simple Object Access Protocol (SOAP) text messages written in eXtensible Markup Language (XML).
Because the web services architecture is an interoperability architecture it identifies those global elements of the global web services network that are required to ensure interoperability between web services using standards and specifications to achieve the interoperability. The existing most common specifications are related to, for example Web Services Reliable Messaging Protocol (WS-Reliable Messaging), SOAP and etc.
SOAP message usually contains an envelope that further contains a header (which may be optional) and a body. The header is typically used to pass “control” information associated with the consumer's web service engagement with the web service provider. The body is used to pass “business” information from the web service consumer to the web service provider. The header of SOAP message may be extended with various information to achieve some additional needs of customers depending on the business relationships in the web services.
A web services framework provides a structure for integration and a foundation for protocols that will support the needs (describing, discovering and exchanging information) of web service applications. Depending on whether the web services framework is implemented on the web service provider or on the web service consumer, the web services framework could be recognized as a client side web services framework that is responsible for sending a web services request to a web services provider or a provider web services framework that is responsible for responding to the web services request. The web services request and the web services response are SOAP messages. The web services framework for processing a web services message is actually a web services runtime framework, implemented in object-oriented software and may be written in Java programming language. The web services runtime framework includes a runtime object that essentially behaves as a manager for the overall process. The runtime object calls upon, at appropriate instances, various other object-oriented structures to fully process a message. On the client side web services framework these various object-oriented structures include: 1) data that describes the applicable web service; 2) information specific to the particular process run being executed, referred to as a configuration context; 3) a protocol chain that contains the object-oriented program code for processing message header information; 4) a transport protocol to convey a message in its transportable format.
The configuration context contains all data for the current processing web services request including the SOAP message. On the client side web services framework there may be additional software that invokes the use of the web service through a proxy for the web service. The proxy is essentially a part of on integrated application that is downloaded to a remote location so that the remote location can call upon methods local to itself that pertain to the application.
Typically, the protocol chain in a web services framework includes several protocols. The protocols with similar functions are usually structured together in an abstraction layer of protocols. In a typical web services framework there are several abstraction layers of protocols. For example, one abstraction layer of protocols within the web services framework is a protocol layer that is responsible for managing, for example, a Web Services Security protocol (WS-Security); a Web Services Reliable Messaging protocol (WS-ReliableMessaging); Web Services Addressing protocol (WS-Addressing), etc. During message processing, protocols usually add to the SOAP message header extension information. This extension information could be implemented in various combinations to effect a broad spectrum of different business relationship models that the web services system can support.
The transport protocol can handle various transport protocols (e.g., HyperText Transfer Protocol Secure (HTTPS), Simple Mail Transfer Protocol (SMTP), etc.) to communicate between the web service consumer and the web service provider at a transport layer.
The WS-ReliableMessaging protocol as a standard protocol at the protocol layer is responsible to ensure the transactions between the two web services across the network. The transaction may be disrupted including messages being lost, corrupted, duplicated, and/or received out-of-order. These disruptions still need to be handled effectively and efficiently in web services systems. A standard Web Services Reliable Message Protocol specification has been authored to fulfill these needs and serves as a building block for varying web services implementations.
Processing of standard WS-ReliableMessaging is handled by the web services framework, in an interoperable and optimized way. Additionally other web services may use capabilities like Reliable Messaging, Addressing, Security or others. All protocols are called by the web services runtime framework in a linear order for each web services request, response or fault SOAP message and may amend the header of SOAP message during its processing. The order of protocol invocation is different depending on where it is used: on the client or on the provider side.
Web services rely on a collection of technologies, standards and specifications, though more new standards are currently being defined to enrich the potential of the web services platform. Enterprise computing system often use web services as a way to distribute information, and many more systems use web services to conduct business processes that require application transaction capability.
Generally an application transaction is a sequence of messages from an application on the web services consumer (a consumer application) to an application on the web services provider (a provider application). Usually at the application level there is logic to ensure that data is protected from accidental modifications that would invalidate it. If a triggering event occurs that upsets the tentative sequence of changes, all the previous changes can be undone to restore the database to its original form. Unfortunately existing web services reliable message protocol fails to support tentative updates for reliable messaging transactions.